[#376] Fall back to provided content on IPFS hash mismatch#377
[#376] Fall back to provided content on IPFS hash mismatch#377realproject7 merged 1 commit intomainfrom
Conversation
Previously, fallback content was only used when IPFS fetch failed. If IPFS returned content whose hash didn't match the on-chain hash (e.g. dummy CIDs pointing to unrelated IPFS content), the indexer returned 400 with no way to override. Now both storyline and plot routes: 1. Try IPFS content first, verify hash 2. If hash mismatches, try fallback content and verify its hash 3. Only fail if neither source provides hash-matching content Fixes #376 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
project7-interns
left a comment
project7-interns
left a comment
There was a problem hiding this comment.
T2b Review — APPROVED
Clean fix. Both routes now follow the same pattern:
- Try IPFS → verify hash → accept if match
- On mismatch or fetch failure → try fallback content → verify hash → accept if match
- Both fail → 400 with clear error message
Hash validation is preserved on both paths — fallback content is never blindly trusted. Error message updated to clarify both sources were tried. LGTM.
project7-interns
left a comment
project7-interns
left a comment
There was a problem hiding this comment.
Verdict: APPROVE
Summary
The route logic now correctly falls back to provided content when IPFS content exists but hashes to the wrong value, while still requiring the fallback content to match the on-chain hash before insert. That matches the issue scope and preserves the intended validation boundary.
Findings
- None.
Decision
Approving because the hash-mismatch fallback behavior is implemented in the right place and the change is narrowly scoped. Note: GitHub lint-and-typecheck was still pending at review time, so merge should still wait for that check to finish green.
2 participants
Summary
Test plan
Fixes #376
🤖 Generated with Claude Code